Herzlich willkommen zur Vorlesung konzeptionelle Modellierung.

Wir haben uns in der Vergangenheit beschäftigt mit der Modellierung von Daten für Datenbank zentrierte Anwendungen.

Die ganze Vorlesung hat sich bis jetzt immer darum gedreht, wie müssen meine Daten strukturiert sein in einer Datenbank,

damit die Datenbank die Ziele erreichen kann, die wir am Anfang gesagt haben.

Wir wollen an einer zentralen Stelle Daten verwalten, auf die viele Applikationen gleichzeitig zugreifen können.

Das Datenbanksystem soll dafür sorgen, dass diese Daten konsistent bleiben, widerspruchsfrei bleiben,

auch dann widerspruchsfrei bleiben, wenn viele eben gleichzeitig darauf zugreifen und wenn Fehler passieren können.

Dafür haben wir eine komplexe Software an Datenbanksystem, das uns das garantieren soll.

Die Konsistenzhaltung wird aber erleichtert, wenn wir auch bei unserem Modellierungsprozess,

wie haben wir unsere Daten strukturiert, wenn wir da sorgfältig vorgehen.

Und welche Methoden man dabei anwendet, das war Kern der Vorlesung bisher.

Wir haben bisher uns überlegt, wie müssen wir unsere Datenbank strukturieren.

Das fing damit an, dass wir gesagt haben, bevor wir überhaupt an die Implementierung denken,

modellieren wir den Ausschnitt der realen Welt, den wir in der Datenbank abbilden wollen.

Die Datenbank repräsentiert immer einen Zustand eines Ausschnitts der realen Welt.

Und den wollen wir modellieren. Das haben wir zuerst mit Hilfe von ER-Diagrammen gemacht,

mit ganz wenigen Modellierungskonstrukten. Dann haben wir gesagt, um da noch ein bisschen mächtiger zu sein,

nehmen wir noch ein paar Modellierungskonstrukte dazu. Dann waren wir bei den erweiterten ER-Diagrammen.

Und dann haben wir uns überlegt, jetzt haben wir ein ER-Diagramm, das beschreibt das,

was wir von der Datenbank abgebildet haben wollen. Das möchten wir jetzt sozusagen implementieren.

Jetzt müssen wir das in die Sprache übersetzen, die das Datenbankmanagementsystem versteht.

Und wir haben uns konzentriert auf relationale Datenbanken. Da werden Daten in Form von Tabellen abgelegt.

Alles muss in Tabellen stehen. Und dann haben wir uns überlegt, wie wir denn ein ER-Diagramm, ein ER-Modell,

abbilden auf eine möglichst äquivalente Menge von Tabellen, sodass die Integritätsbedingungen,

die wir im ER-Diagramm formuliert haben, möglichst vom Datenbanksystem überwacht werden können,

sichergestellt werden können. Dazu haben wir dann Methoden kennen gelernt oder strukturiert

der Vorgehensweise kennengelernt, wie man da Schritt für Schritt vorgeht.

Und dann haben wir uns noch überlegt, wie man denn systematisch sicherstellen kann,

dass diese Tabellen, die wir jetzt erzeugt haben, auch redundanzfrei sind. Das war dann die Normalisierung.

Da haben wir uns überlegt, gibt es da eventuell funktionale Abhängigkeiten zwischen den Attributen

in einer Tabelle? Und wenn das so ist, dann liegt der Verdacht nahe, dass wir eine Tabelle haben,

in der eigentlich verschiedene Entity-Typen mit repräsentiert werden. Und wenn das der Fall ist,

dann tritt typischerweise da Redundanz auf und es treten Anomalien auf, die wir eigentlich vermeiden wollen.

Jetzt verliere ich hier den Strom. Diese Anomalien, die haben wir dann vermieden, indem wir unsere Tabellen,

wenn wir sowas festgestellt haben, aufgesplittet haben in mehrere Tabellen.

Dann waren unsere Tabellen mehr oder weniger redundanzfrei und zum Schluss haben wir uns jetzt überlegt,

jetzt haben wir ein wunderschönes redundanzfreies Datenbankschema, jetzt wollen wir mit diesen Tabellen arbeiten.

Wie machen wir das? Dann haben wir uns zunächst überlegt, welche Operationen man auf Tabellen anwenden kann.

Da waren wir bei der Relation Algebra, da haben wir spezielle relationale Operatoren kennengelernt,

Selektion, Projektion, Verbund und wir haben gesagt, eine Tabelle ist eine Menge von Tupeln,

also kann man da auch Mengenoperationen auf solchen Tabellen anwenden. Das war alles noch relativ mathematisch.

Und dann haben wir uns überlegt, was eigentlich eine Datenbanksprache können muss.

Dann waren wir beim Kapitel SQL gelandet, Structured Query Language, das ist das, was wir letzte Woche gemacht haben.

Und wenn wir damit fertig sind, damit werden wir heute fertig, haben wir eigentlich den Teil Relationale Datenbanken

mehr oder weniger abgeschlossen. Also kurze Wiederholung nochmal, was wir mit SQL gelernt haben.

Wesentlich bei SQL ist, dass es eine deskriptive Anfragesprache ist. Wir formulieren in einer SQL Anfrage

nicht, wie das Datenbanksystem vorzugehen hat, um bestimmte Datensätze zu finden,

sondern wir beschreiben sozusagen die Qualität des Ergebnisses. Welche Eigenschaften muss die Menge meiner Ergebnis-Tabelle sozusagen erfüllen?

So eine SQL Anfrage, die hat im Prinzip immer die gleiche Struktur.

Hier sehen wir ungefähr die Syntax. Auf Folie 27 haben wir eine vereinfachte Syntax dargestellt.